A “model” generally describes one or more complex application artifacts (e.g., business processes, data structures, structure and behavior of software systems or other technical and/or business components, etc.) in a formalized fashion. A model can use modeling primitives and/or conventions of a well-defined “abstract language,” which oftentimes is referred to as a metamodel. Some common metamodels are the UML family of modeling languages (e.g., UML class diagrams, UML collaboration diagrams, etc.), the BPMN metamodel, the ARTS family of modeling languages (EPC, VAC, FAD, etc.), the entity-relationship (meta)model (ERM), the relational (meta)model, etc. A metamodel, being an abstract language, may be thought of as a collection of modeling elements that can be used or “instantiated” to describe the actual models. For instance, in a UML class diagram, modeling elements include classes, associations, properties, etc., whereas the model elements in the relational model include relations and their attributes. These modeling elements can be arranged in a variety of well-defined ways to build formal models representing potentially complex business and/or technical processing or other flows.
A metamodel is in principle independent of a concrete notation and therefore may be thought of as an “abstract language,” as indicated above. For instance, a metamodel may define only the language concepts and the rules for their use to form a valid model for the metamodel itself. To do actual modeling with a metamodel, however, a concrete notation is required. Notations of metamodel elements include, for example, boxes with three “compartments” that represent UML classes, labeled rectangles and diamonds used to represent entities and relationships in the ERM, etc.
A common trait of many metamodels is that corresponding models can be represented as a graph including nodes and edges, which collectively can be referred to as the graph's “elements.” Computer systems handling different “kinds” of models (e.g., so-called model management systems) often use some kind of graph model as internal representation for all kinds of models.
Model merging involves creating a single merged result model C, from two models A and B (where A, B, and C can be expressed in the same metamodel), that possibly describe the same or overlapping sets of application artifacts (e.g., the same software system, the same business process, etc.), but describe these artifacts differently. For example, A and B could be two versions of the same original model that were modified independently. As another example, A and B might describe different aspects of an application domain that share some overlap.
It would be desirable to run a merge function to deliver a merged model C that does not contain redundancies. That is, it would be desirable to help ensure that all model elements that appear in both A and B appear at most once in the merged model C. Depending on the exact purpose of C, it oftentimes is desirable to preserve all elements that are either in A or B. Doing so may help to reduce the likelihood of information being lost from the input models. However, this is not a general requirement for merging. It also would be desirable to have the merged model C be consistent and well formed, e.g., so that it meets the constraints of its respective metamodel.
With models being some kind of graphs, model merging is a different challenge than the more common (and usually line-wise) merging of text files as it is done, e.g., in version control systems. Text-based merging of models is theoretically possible if there is a textual (e.g., XML-based) notation for their respective metamodel. However, text-based merge tools are not natural tools for handling the merging of models. For example, most textual representations are ill-suited for direct use by humans and are only meant as storage formats or for model interchange. In particular, the structure of the (linear) textual representations usually differs considerably from the non-linear, graph-like structure of the model itself, making it difficult and cumbersome to work directly with these representations. Second, even small changes of a model can lead to significant changes of its textual representation, making it hard to differentiate between the actual changes on the model level and purely “syntactical” changes implicated by the textual representation. Text-based tools therefore are not really appropriate for model merging.
When designing a merge system for merging two models A and B, a function may be provided for identifying pairs of elements ai and bj from A and B, respectively, that are considered identical (or at least elements that after a successful merge operation should appear only once in the resulting merged model C). “Identical” element pairs are discussed herein as a mapping relation mapAB: A×B.
It will be appreciated that mapAB, being a relation, need neither be injective nor surjective nor a function. In general, model elements from A need not have counterparts in B, and vice versa, and an element ai from A could possibly have several “identical” elements bi1, . . . , Bin in B and vice versa. In literature, techniques for producing such a mapAB from two models A and B are called schema or model matching techniques. In other scenarios, such a mapAB can also result from the process that created models A and B.
Based on the content of mapAB, it is possible to distinguish different categories of (pairs of, groups of, individual, etc.) objects from A and B:                If two objects aiεA and bjεB are identified as identical by mapAB (e.g., (ai,bj)εmapAB), and if no other entries involving ai or bj exist in mapAB a (∃ax s.t. (ax,bj)εmapAB∃by s.t. (ai,by)εmapAB) and if ai and bj agree on all properties that are relevant for the merge method (e.g., certain attributes, etc.), then ai and bj can be called equal. If ai and bj differ in some of their merge-relevant properties, these objects can be referred to as having been changed.        Objects aiεA (bjεB, respectively) for which there exists no object bjεB (aiεA, respectively) such that (ai,bj)εmapAB (∃bjεB s.t. (ai,bj)εmapAB) (∃ai s.t. (ai,bj)εmapAB, resp.) may be called added in A (added in B, respectively).        If two objects aiεA and bjεB are identified as identical by mapAB (e.g., (ai,bj)εmapAB), and if other entries involving ai or bj exist in mapAB ((ax s.t. (ax,bj)εmapAB)(by s.t. (ai,by)εmapAB)), these objects may be referred to as being conflicting.        
With this information, a merge method may create a consistent result model C. While the handling of objects that are equal is seemingly straightforward, it may be the case that decisions have to be made for all other kinds of objects if and how to accept them into the result model C. These decisions may depend on, for example, the intended purpose of C, the details of the conflicts, the context in which A and B where created, etc. These difficulties demonstrate that model merging currently is inevitably a manual task of which only certain trivial tasks can be safely automated. This also implies that, in general, a human has to decide which elements and which properties to take from A and which from B, for inclusion into the result C.
The ARIS model transformation component, provided by the assignee of the instant invention, allows users to declaratively describe how models of one type can be transformed into a semantically related model of a different (or sometimes also the same) model type. An example for such a transformation is shown in FIG. 1. In FIG. 1, a business process modeled using the event-process chain (EPC) metamodel is transformed into an equivalent process in the “business process model and notation” (BPMN) metamodel. This transformation can be referred to as an EPC-2-BPMN transformation. Although the EPC metamodel may be meant to be used by business-oriented users to capture business processes as they are (or should be) handled in an organization, BPMN is a metamodel and notation that also covers more technical aspects. Using the EPC-2-BPMN transformation, a BPMN can be created from an EPC to be used as starting point for enriching the business view of a process with technical details to ultimately make the process executable by a suitable runtime environment like a workflow management system (WfMS). However, the present invention is not limited to the modeling of business processes, but may well be used in other scenarios such as, for example, the systems engineering of complex technical products. For example, the development process of a vehicle is nowadays largely model based. In this scenario, the various vehicle components are typically modeled on a system-wide level defining the main mechanical components such as the chassis, engine and power train, as well as electric/electronic components such as rain sensors, speed-limiters, embedded processors and the related software. Further, the individual vehicle components are themselves defined by more and more concrete technical model as the development process continues, ultimately leading to a variety of technical component models on different levels of abstraction, but yet strongly interrelated.
The description of the transformation is given by so-called transformation patterns or rules, which specify how individual or groups of elements of the source model type are translated into corresponding elements of the target model type. The ARIS model transformation, in particular the graphical way to describe transformation patterns, is discussed in detail in U.S. Publication No. 2009/0265684, the entire contents of which are hereby incorporated herein by reference. A transformation pattern includes a source pattern, a target pattern, and a mapping. The source pattern can be understood as a graphical query over the input model(s) that describes the structures of the source model to be found and transformed. Each region of the input model that conforms to the structure described by a source pattern can be considered a match for this rule. A transformation pattern's target pattern describes what elements and structures of the target model type are to be created for each match. The structure that is created in the result model for each match can be called a fragment. Of course, transformation patterns or rules may be defined in other ways such as, for example, by hard-coding specific functionality.
Using the mapping part of a rule, the developer can graphically define how attributes and properties of the source model elements matching the source pattern are to be transferred into the attributes and properties of the target model elements. By placing additional operators in the mapping and connecting them accordingly, the creation of complex mappings can be done graphically, e.g., without the hurdle of handling a complex expression syntax, as it is found in other model transformation languages.
Several simplified examples for transformation rules are set forth below. FIG. 2 is an example pattern for transforming a function to an abstract task. The source pattern of the rule “Function to abstract task” in the upper-left of FIG. 2 includes only an EPC function. The target pattern shown to the right declares that such a structure is to be translated into a BPMN abstract task object, which is to be placed into a lane, with the lane being placed into a pool object. The mapping shown in the lower part of the drawing indicates that the abstract task object is to carry the same name as the matched source function, and that the lane into which the manual task is to be placed is to be named “default lane.”
FIG. 3 is an example pattern for transforming a function with an organizational unit to a manual task. The rule “Function with organizational unit to manual task” shown in FIG. 3 can be considered a special case of the rule “Function to abstract task” from FIG. 2. As above, the source pattern includes an EPC function, but the function in this example is connected with an organizational unit. It is noted that objects that do not directly describe the main process flow but which instead are placed adjacent to an element of the main process flow (such as the organizational unit element in this example) may be referred to informally as satellite objects. The target pattern in FIG. 2 seems to be very similar to the one from the FIG. 2 example rule. However, instead of creating an abstract task, a manual task object is being created. Further, instead of placing the task into a “default lane,” the lane is now named based on the source organizational unit element.
The degree of complexity transformation rules can have can be quite large. For instance, FIG. 4 is another example rule that creates a special kind of task based on a specific constellation of EPC elements. In FIG. 4, an EPC function connected with a business service is translated to a BPMN service task. As can be seen from FIG. 4, the source and target patterns of this rule include assigned models. For the source pattern to match in this example, an assigned model must exist at the business service. In this model, an additional software service type object that describes the business service in more detail has to exist. This object itself in this example must again be detailed by second source side assignment, as shown in the lower-left corner of FIG. 4. The rule will match and create a corresponding Service Task only if this exact structure is found, and an assigned model will be placed at this service task that holds additional information about the service task based on the assignments matched by the source pattern.
Similar specializations may exist for different constellations of EPC functions and satellite objects that create different types of tasks. With additional rules that specify how to transform other elements of an EPC model, like events and rules into corresponding elements in BPMN, the EPC-2-BPMN transformation can translate all elements of an EPC model that are also relevant on the technical level into a semantically equivalent BPMN model.
One challenge in the design of the EPC-2-BPMN transformation involved the handling of ambiguities. Consider, for example, a function that is connected to both a business service and an organizational unit. In this situation, both the “Function with organizational unit to manual task” and the “Function with business service to service task” patterns would match, but would disagree in their result (e.g., symbol type, placement into a lane etc.). One possibility for addressing this issue involves prioritizing the patterns in a transformation (e.g., preferring the creation of a service task in this situation). Another option involves designing patterns that could “compete” about the same source model elements in such a way that they are only applicable if exactly one of them matches unambiguously for a given function. Following the former approach, the ambiguous example function would be transformed to a manual task, as the manual task pattern has a higher priority.
Business process management (BPM) aims to capture, analyze, and optimize or improve how companies perform their processes, and attempts to provide IT support for conducting the processes more efficiently in everyday business. One aspect of BPM involves introducing workflow management systems (WfMS) that control the execution of processes, both regarding activities performed by humans (e.g., with varying degrees of IT support) and activities performed in completely automated manners and possibly with the help of software and/or other technical systems. In the conventional, manual approach, BPM starts with human experts analyzing how an organization is currently conducting its business processes. The results of this analysis are captured in various ways, either informally as requirement documents, or in a semi-formal notation like the aforementioned EPCs. After an optional optimization step, these business-centric process descriptions are cast into a technical process description that can ultimately be executed by the WfMS. As part of this implementation step, aspects that are not captured by the business process descriptions may be filled in, e.g., by identifying and connecting information systems that are needed for a process, etc. Being a fully manual development task, this approach is both slow and costly.
Model-2-execution (M2E), however, aims to reduce the enormous manual development effort of BPMN by automating parts of the translation of the business-centric process descriptions into executable, technical specifications. An aspect of M2E thus involves adapting the concepts of model-driven development (MDD) to the BPM world, e.g., by replacing a large part of the manual work with model-2-model transformations. The EPC-2-BPMN transformation introduced above may be used as a transformation in model-2-execution approaches. In MDD terminology, the EPC-2-BPMN transformation can be understood as a transformation from the computational-independent model (CIM) that does not capture aspects related to the implementation with an IT system, to the platform-independent model (PIM). A PIM may cover aspects relevant for the implementation, but may nonetheless still be independent of a concrete implementation technology used (e.g., in the case of BPM, the concrete workflow management system that is used, or how the WfMS communicates with other required IT systems, etc.).
In the context of the model transformation in model-driven development in general, and specifically also in MDD for BPM as it is pursued by the M2E approaches, the situation often arises that after a creation of the initial transformed model T via a transformation run, the source model S is changed by a business user, yielding a modified source model S′, as illustrated in FIG. 5. To propagate these changes to the technical BPMN layer, it may be possible to transform S′ again, yielding a new transformed model T′. However, in the meantime, a process engineer might have modified the original BPMN model T and augmented it with technical information, that way yielding a modified BPMN model T″. In this case, it is not desirable to simply replace T″ with T′ to get the business-level changes to the technical level, as this would lose all changes by the technical user that yielded T″. Unless either T′ or T″ can be discarded as a whole and the changes from only T″ or T′ can be taken into the result, the independent changes in T′ and T″ may need to be combined into a single, consistent merged model TM by merging these two models T′ and T″. In this merge process, T′ (e.g., the model resulting from transforming the modified source model S′) may be referred to as the new transformed model, and T″ may be referred to as the merge target model.
In the FIG. 5 example, the business user adds a function F3 to the process as an (exclusive) alternative to F2 to create S′. In the original transformed model T, the process engineer adds an additional task F2b to create T″. F2b could represent a task that is necessary from a technical standpoint, but need not be reflected on the business level. When S′ is now transformed to obtain T′, it can be seen that T′ and T″ differ and that a merge may need to be performed to obtain a result that reflects the changes in both models as good as possible.
As discussed above (e.g., in connection with the general model merge problem) to be able to successfully merge the two models T′ and T″, it would be desirable to provide a way to identify elements that are to be considered “identical” for the purpose of merging, e.g., a way to obtain a mapT′T″. Instead of using inherently fuzzy methods such as, for example, guessing pairs of identical (e.g., mergeable) objects based on their properties (e.g., name, type, etc.), or even leaving the identification of pairs of identical objects completely to the user, the transformation itself my place “trace” information on all elements that it creates. This trace information may include for each element ti in the transformed model, among other things, information about which transformation rules were involved in the creation of ti, the identities of the source element(s) in model S that were “responsible” for the creation of ti (e.g., those source model elements that were matched by the source patterns of the different transformation rules that helped to create ti), etc. Two objects t′εT′, t″εT″ may be considered identical (e.g., will be found in a tuple of mapT′T″) if they agree to a sufficient degree in their trace information and some additional properties. While this may sound counterintuitive at first, this merge semantics may be valuable because, in practice, models tend to have many objects whose properties (e.g., type, symbol, attributes such as name, etc.) are equal, and that are consequently transformed to result model objects that are also equal. Thus, if the identity of their source model elements were not used as a distinguishing criterion, it might not be possible to disambiguate these equal (but not identical) result model elements and thus it might not be possible to perform proper non-ambiguous merging. Further, by merging via source object identity, it also may be possible to transfer changes of properties (e.g., a renaming of an EPC object) during the merge. If the merge decision were based on properties and if these properties were modified on either source or target model, the objects could not be merged.
In the existing implementation of the model merge in the scope of the ARIS model transformation, the transforming of S′ into T′ and merging T′ with the merge target model T″ with T′ is an integral process. The user may pick the source model, the merge target model, and may be presented with a single model that illustrates the conflicts between T′ and T″, as shown below in FIG. 6. This model may be referred to as the conflict model TC. In the conflict model, the user may resolve the remaining conflicts to create the final merge model TM. Conflicts may be indicated, for example, with graphical icons next to the conflicting elements. These icons may also be referred to as the corresponding element's “merge state.”
With the mapT′T″ obtained via the transformation's trace information as discussed above, the conflict model may be created as follows:
Pairs of elements aεT′ and bεT″ that are identical or changed are shown only once in the result, like the functions F1 and F2, the start and end events, the lanes, and the pool in this example. These elements have no conflicts or “merge state” associated with them. It is noted that that attribute changes that occur in S′ may be written into the existing objects, e.g., the source model silently overwrites any attribute changes in the target. Thus, for the purpose of the merge in the ARIS model transformation, equal and changed objects may be handled identically.
Elements that are found in T′ but have no counterpart in T″ (according to mapT′T″) are added to the conflict model and flagged with the merge state “added by transformation” (or “added in source”), indicated by a green plus icon next to these elements. In the example, it can be seen that the BPMN gateway created from the new XOR rule, the task F3 created from the new function F3, and the new “End 2” end event are marked as such, as are all connections between them. Further, the connection between task F2 and the end event “End” is marked with “added by transformation.” This might seem non-intuitive, as the corresponding connection has not been changed from S to S′. However, the corresponding connection in T″ had been deleted when F2b was inserted by the process engineer. In an ideal scenario, the actual merge state of this connection might have to be “deleted in target.” The merge, however, may not be able to distinguish between these two situations. To be able to correctly flag this connection as “deleted in target,” it may be necessary to maintain the complete change history of T′, which could be difficult or impossible or simply not worth the tradeoffs between size, space, complexity, possible processing gains, etc.
For elements that are found in T″ and have no counterpart in T′, two situations can be differentiated. If such an element t was created by the (original) transformation (that can be determined based on the presence of trace information on t), this may indicates that the source model S′ has changed in a way such that an object corresponding to t is no longer created by the current transformation. Consequently, it may be added to the conflict model and flagged with the merge state “deleted by transformation,” e.g., as indicated by a red minus icon. In this example, the connection between F1 and F2 that was in the original T and was preserved by the process engineer when creating T″ is marked as such, because the connection no longer exists in T′, since the corresponding connection in the EPC has been deleted by the business user when going from S to S′.
If an element t was manually added to T″, which can be recognized by the absence of trace information, it also may be added to the conflict model and flagged with the merge state “added in target,” indicated by a blue plus icon. In this example, the function F2b and incident connections are marked as such.
Together, each object that has one of the three merge states can be referred to as an atomic conflict.
Via the user interface, the user can individually accept or reject the individual atomic conflicts. When accepting an “added by transformation” or “added in target model” conflict, the corresponding model element is retained and the merge state is removed, to indicate that the conflict has been resolved. When rejecting such a conflict, the model element is deleted. When accepting a “deleted by transformation” conflict, the element is deleted. When rejecting it, the element is retained and the merge state is removed.
While it is possible to handle the resolution of merge conflicts by individually accepting or rejecting atomic conflicts, this approach is not very convenient and can sometimes confront the user with internal details of the model representation in ARTS. Business users may be presented with potentially complicated technical details, technical people may be presented with business aspects that they do not necessarily understand, etc. To make the resolution of merge conflicts easier, the concept of high-level conflicts has been introduced by the assignee of the instant invention. In this regard, it is possible to use the basic information obtained during merging as described above including, for example, the different merge states of objects (equal, changed, added in A/B, conflicting, etc.) and their constellations in the models being merged, to recognize high-level merge conflicts. Instead of leaving the user to resolve the merge conflicts on the level of the atomic elements (e.g., objects and connections with a non-empty merge state), high-level merge conflicts may capture the semantics of the differences between the models being merged on a larger scale (e.g., possibly covering a very large number of model elements in one conflict) and—most of the time—allow the user to resolve them easily and quickly within a single operation. This approach to making conflict resolution both easier and more convenient is described in detail in U.S. application Ser. No. 13/024,646, filed on Feb. 10, 2011, the entire contents of which are hereby incorporated herein by reference.
The merge view is a tool that helps make the task of interactive merging easier for the user, especially for larger models. It displays the source model and the conflict model side-by-side, as illustrated below in FIG. 7. It then allows the user to find out how each element in the target model, shown to the right, corresponds to element(s) in the source model, shown to the left (or vice versa), simply by selecting the element the user is interested in. If an element in the source model is selected, the corresponding elements in the target model are selected, and vice versa, as shown in FIG. 7 for EPC Function F1 and its corresponding BPMN task. In addition to selecting the corresponding elements, the respective other view's viewport is automatically scrolled to the selected elements, a feature that can be beneficial when working with models that are too large to fit on one screen. The correspondence information displayed by the merge view is derived from the transformation trace information discussed above.
In general, the relationship between source and target model elements can be of any cardinality up to many-to-many, e.g., such that each source (target) element can have zero, one, or many corresponding elements on target (source) side.
As indicated above, the assignee has provided merge functionality (including the complex conflict detection covered by U.S. application Ser. No. 13/024,646) in the ARIS model transformation component. In addition, the ARIS model merge component, provided by the assignee of the instant invention, works with ARIS, which offers XML-based import and export modules for transferring ARIS models between different ARIS databases. For example, a model M may be created in DB X, exported to a file, and imported into DB Y. Assume that model M is now changed in X, yielding a modified model M′, and at the same time, the originally imported model M is also changed independently in DB Y, yielding model M″. M′ is now exported again into an XML file, and imported into DB Y. Because M′ and M″ are different versions of the same model (a fact that can be recognized via unique identifiers on the model and its model elements), a model merge may need to be performed. When importing M′, the user can select whether or not model M′ (setting “source overwrites target”) or model M″ (setting “target preserved”) will prevail in case of conflicts. These settings can be set differently for objects, connections, models, etc. However, this merge technique does not offer selective control over how individual conflicts are resolved. In this sense, it is not interactive. It further does not allow users to bring a selection of changes from model M′ back to M″.
A large number of computer-aided software engineering (CASE) tools claim variable degrees of MDD support. However, aside from some “convenience” features, the actual application behavior typically has to be implemented by hand, e.g., by “filling out” empty method bodies or adding and detailing aspects that were not fleshed out in full detail in the models. Other manual work includes the customization of the aforementioned out-of-the-box features (like customizing the default object serialization so that it conforms to existing storage formats or database schemas).
In roundtrip engineering for software engineering, the artifacts generated from the model are in general not other models, but rather program code (e.g., structured text). Further, a general common assumption of roundtrip engineering approach in the software engineering domain is that in general, all changes performed on the PSM level that could be represented with the modeling language used for the PIM should be propagated. In contrast, in the scope of the M2E roundtrip, only selected aspects that have been added to or changed in the BPMN model should actually be propagated. Consequently, in M2E, the decision to propagate a change is a conscious choice by a user on a case-by-case base, guided by the semantics of the artifacts involved.
Another issue that arises with roundtrip engineering in software engineering contexts is that many aspects that can be represented explicitly with dedicated model elements (e.g., containment or aggregation associations) are mapped to the same basic elements of the target programming language (e.g., object references). Therefore, it is often difficult to recognize such aspects of modeling based on the code and properly propagate them back to the model level.
The functionality of the ARIS model transformation and the interactive merge as discussed allows merge conflicts to be resolved by accepting or rejecting changes in the BPMN model, whether they result from changes in the EPC or from direct changes in the BPMN model itself. As an example, consider FIG. 8, which shows a very simple merge scenario. EPC S is first transformed to a corresponding BPMN model T. Here, the process engineer makes a technical change by deleting the connection from task F1 to the end event, adding a new task “F2 added in BPMN,” and connecting it with F1 and the End event, thereby creating the modified transformed BPMN model T″.
In parallel, a business user makes a business change to the EPC by inserting another function F0 between the start event and the function F1, yielding the modified source model S′. If S′ were to be transformed without a merge, the new transformed model T′ would be obtained. If either T′ or T″ were taken as the new BPMN model, the changes of either the process engineer or the business user, respectively, would be lost. To avoid such scenarios, interactive merge techniques can be used to reconcile the parallel changes. By merging T′ with T″, a conflict model TC is produced. In this model, the high-level merge conflict detection discussed above identifies two high-level conflicts, namely, the addition of F0, and the deletion of the direct connection between the start event and F1 is recognized as a “replacement in source” conflict. This conflict can either be accepted (leading to the removal of the direct connection marked with the red minus sign in the conflict model and keeping F0 and its incident connections and removing their green plus sign merge state), or rejected (which causes the deletion of F0 and its connections, and removes the red minus sign merge marker from the connection between the Start event and F1).
The second high-level “replacement in target” conflict shown in detail to the left of FIG. 9, which demonstrates the options for resolving the “replacement in target” high-level conflict, is caused by the addition of the new Task “F2 added in BPMN” to the BPMN model by the process engineer. If this high-level conflict is accepted, the newly added task and its incident connections are kept in the result, their blue plus sign merge state is removed, and the green plus sign connection from F1 to the end event is removed, as shown on the upper-right of FIG. 9. If the high-level conflict is rejected, the connection from F1 to the end event is kept, its green plus sign merge state is removed, and the new task “F2 added in BPMN” and its incident connections are removed, as illustrated on the lower right of FIG. 9.
Although the concept of high-level conflicts makes it easier for the user to resolve the merge conflict caused by the addition of an element in the BPMN model, this conflict resolution only affects the BPMN model. The EPC is left unchanged. While this is a desired result in those cases where the additions and changes in the BPMN model only represent a technical detail that has no implications for the business view of our process (e.g., do not require changes of the EPC source model), there are many situations where it would in fact be desirable to have individual (but not necessarily all) changes made in the BPMN model to be reflected on the EPC, because they are in fact relevant for the business user. Thus, this current approach does not support the person performing the interactive merge in propagating such changes from the technical BPMN level to the EPC level. As explained below, however, there are a number of drawbacks to manually solving these issues.
With a manual propagation, the user has to change the EPC in a way such that the new transformation result after the change gives the same result as currently provided in the BPMN, or make the changes made in the BPMN that had been propagated to the EPC appear as if they had “always been modeled like that” in the source EPC model.
FIG. 10 illustrates how a user performing an interactive merge can manually perform a propagation of the BPMN-side addition of the abstract task “F2 added in BPMN” (referred to below as F2BPMN) as in the FIG. 8 example. Here, the user manually creates a like-named function in the EPC F2EPC and connects it analogously to how F2BPMN is connected with its surroundings in the BPMN model T″. The result of this manual propagation is shown on the upper-left of FIG. 10 as EPC S″. The user basically creates a situation so that the corresponding transformation pattern(s) (which here would be the “Function to Abstract task” pattern we introduced above in FIG. 2) match and in the next transformation run would create the same situation that exists in the BPMN model because of the manual changes that were made there.
One disadvantage of such a manual approach relates to the effort involved for the user. While it may seem straightforward in this simple example, once more than a few changes have to be propagated to the EPC, this approach can quickly become a repetitive, time consuming, and error-prone task.
In addition, a correct propagation is not always as simple and obvious as in this example where the creation and connection of only a single object in the EPC was involved. Consider, for example, the “Function with business service to service task” transformation rule discussed in connection with FIG. 4. If there were a desire to propagate a service task that was added to the BPMN model so that this rule now matches, a quite complex object structure, including several assigned models, would have to be created correctly. To be done correctly, it may be necessary to have a very detailed understanding of the semantics of our EPC-2-BPMN transformation, which cannot always be reasonably expected from the users performing an interactive merge. The problem of correct and consistent model propagation is similarly severe in the above-mentioned systems engineering context. For example, strong interrelations exist between the different technical models of the vehicle components of an automobile, since the vehicle components typically have multiple interaction points (consider, for instance, an optical or radar-based distance sensor component that is shared by both a software-based speed-limiter and an emergency breaking component). Such strong interrelations as well as other feature interactions can make the correct and consistent propagation of model elements between different model levels quite difficult.
Even if the manual effort and the required internal knowledge about the transformation were considered acceptable, such manual change propagation may also have technical restrictions. Referring still to the example manual propagation from FIG. 10, if S″ were transformed again, a new result model T′″ including a task “F2 added in BPMN” (F2EPC′) created by the transformation of F2EPC would be created. At first glance, this model appears identical to the modified transformed BPMN model T″ where the user manually added the new business-relevant task F2BPMN. Consequently, one might be tempted to expect that if these two models were to be merged that no conflict would be shown involving the Task “F2 added in BPMN,” and that the manual change propagation was successful. However, as we discussed above, the transformation's built-in merge functionality does not rely on the properties like object type, symbol, or name of a pair of objects to determine whether or not they are mergeable, but instead uses the transformation's internal trace information. As explained above, this trace information includes for each result object of a transformation both the set of source model objects that contributed to the creation of a transformation result and the transformation patterns that were involved in its creation. Consequently, if a user were to perform a transformation plus merge of S″ into T″, the Abstract Task F2BPMN′ created by the transformation from the manually added EPC function F2EPC could not be merged with the Abstract Task F2BPMN that was added directly to the BPMN, since they disagree in their trace information, inasmuch as F2BPMN′ indicates that it originates from F2EPC, while F2BPMN does not indicate any source object because it was never created by a transformation in the first place. The conflict model TC as shown on the bottom of FIG. 10, which contains both Abstract Tasks F2BPMN and F2BPMN′, therefore would be produced.
The high-level “replacement in target” conflict could be resolved, and either the task F2BPMN′ coming from the EPC via the transformation (marked as “added in source” with the green plus sign) or the task F2BPMN from the BPMN (marked as “added in target” with the blue plus sign), could be kept. Doing so, however, would still not provide the desired result. If F2BPMN′ were kept by rejecting the “replacement in target” conflict, a proper correspondence between the objects in the EPC and the BPMN model would be produced, but any additional technical details the process engineer might have put into the discarded F2BPMN (e.g., setting technical attributes or adding assignments with information about the invoked service etc.) would be lost. On the other hand, if F2BPMN were kept instead, this technical information would be preserved, but no proper correspondence would exist between F2BPMN and F2EPC. Not only would these two objects not be shown as corresponding in the merge view, but changes to F2EPC (e.g., a renaming) would not be propagated to F2BPMN in future merge operations.
The example discussed immediately above dealt with the propagation of model elements that were new to the target model. Another common type of propagation oftentimes needed in MDD scenarios involves not only additions of new elements, but also augmentations, refinements, or other changes to existing target model elements that were created by the transformation from elements in the source model that are to be reflected by corresponding changes in the source model. In the example shown in FIG. 11, the Abstract Task F1 created by the transformation out of a simple EPC function without any “satellite” objects is refined by the process engineer into a service task. The service invoked by the task is specified in an additional model assigned to the service task.
If transform and merge operations were now performed, a merge conflict would be produced not because the trace information differs, but because the objects deviate in symbol type (abstract task vs. service task) and the number and type of assignments (no assignments vs. a function allocation diagram), as shown on the bottom of FIG. 11. Again, it is possible to resolve the conflict if it is found that the BPMN-side change is not relevant for the business user. As before, this would come at the cost that any renaming, etc., of F1 in the EPC would not be propagated. However, if it is thought or needed that the EPC should reflect the change, a manual propagation of the BPMN-side change as shown below in FIG. 12 can be performed. To make the EPC function F1 be translated to a service task that looks just like the one the process engineer created in the BPMN model, the set of assigned models and associated objects shown at the upper-right of FIG. 12 can be added, that way helping to ensure that F1 is now successfully matched by the source pattern of the transformation rule “Function with business service to service task” from FIG. 4. This example helps illustrate that once one tries to propagate a change involving a more complex pattern, the effort involved and the knowledge needed to “get it right” quickly becomes prohibitive in practice. If the manually modified EPC were again transformed and merged with the BPMN model, a similar situation as before would arise. That is, although the two would look identical, the two service tasks F1 from T′″ and T″ could not be merged successfully, with all the negative consequences that this has for the correct functioning of the merge view and the future automated propagatation of changes to F1EPC to F1BPMN, discussed in the previous example from above.
Thus far, problems of manually propagating additions or changes in the (BPMN) target model to the (EPC) source model have been discussed. As shown above, there oftentimes will be a manual effort involved in such a task for anything but the most trivial cases, and limitations of this manual approach that are related to the way the model merge decides whether two objects are mergeable have been described. Aside from additions and changes, a third kind of modification operation that can be performed on the target model relates to deletions.
FIG. 13 illustrates an example for a deletion on BPMN side: The process engineer removes the manual task object “F2” and “bridges” the gap that is created in the process flow by adding a direct connection between F2's former predecessor manual task “F1” and its former successor end event “End”. If transform and merge operations were now performed again, a “replacement in target” high-level conflict would be generated in the resulting conflict model TC, as shown near the bottom of the drawing. Accepting this conflict (accepting the replacement of F2 and its two incident edges with a single edge) would lead to the result shown to the lower left, whereas rejecting it would retain the original transformation result as shown to the lower right of the drawing.
If the change on the technical BPMN level is now considered relevant for the business level, the deletion could again be propagated manually, as shown in FIG. 14. Here, the EPC is changed in accordance to the change on BPMN level, such that the function “F2” and its neighboring occurrence of the “Otto” Organizational Unit object are removed. If the modified source model were now transformed, the result would be structurally identical to the original BPMN model modified on source side. If transform and merge operations again were performed, the result (whether there are conflicts in the merge) would depend on the details of the merge method (or the way the mapping relation mapAB is obtained) used. If the merge method considers two connections mergeable if their start and end objects are mergeable, no merge conflict will arise, as shown to the left on the bottom of FIG. 14.
If, however, the merge method uses the identity-based mergeability decision discussed above not only for deciding the mergeability of objects, but also for connections, a conflict like the one shown in the lower right of FIG. 16 could arise. In these situations, as with the addition and modification operations discussed before, a manual propagation of the changes on the technical level to the business level would not be possible, as the user would need to manipulate the internal trace information, etc.
Thus, it will be appreciated that there is a need in the art for techniques that help support users manage model transformations and/or merges, and/or approaches that help overcome the above-described and/or other complications that arise when attempting to transform and/or merge models. Those skilled in the art of model-based systems engineering will appreciate that these problems are equally relevant in all of the above-described use cases, including the manufacturing of complex technical products, the model-based controlling of manufacturing machinery as well as the modeling of business processes.
One aspect of certain example embodiments relates to an automated approach for propagating (or pulling up) business relevant changes made in a technical model (e.g., BPMN model) to the business-oriented model (e.g., EPC model). Doing so may reduce and sometimes eliminate the need for manual change propagations. According to certain example embodiments relates to avoiding conflicts, e.g., by making certain changed objects appear as if they were created by the “pulled-up” EPC object by changing its internal attributes needed for the merge. Optionally, the BPMN model may be “corrected” so that the merge is possible without conflicts.
Another aspect of certain example embodiments relates to a selective, partial inversion of a transformation from the technical model to the business-oriented model, or vice versa.
Another aspect of certain example embodiments relates to a pull-up operation that includes enablement checking (e.g., determining whether the pull-up can be applied to a selected object) and pull-up execution.
According to certain example embodiments, enablement checking may be separated into multiple phases. In a first example phase, a coarse check may be performed to determine whether the pull-up operation makes sense, possibly returning a Boolean true/false value. In a second example phase, a more detailed check may be performed to determine whether the pull-up really can be executed, possibly returning a list of reasons informing the user why the pull-up cannot be applied.
According to certain example embodiments, the pull-up execution may include, for instance, creating the object(s) in the business-oriented (e.g., EPC) model; updating relevant internal attributes of the technical (e.g., BPMN) objects that allow for the successful merge; optionally correcting user-introduced errors in the technical (e.g., BPMN) model; and properly connecting the pulled-up objects with their surroundings.
Another aspect of certain example embodiments relates to connecting pulled-up objects with their surroundings so that, after the propagation, the objects appear as if the current business-oriented (e.g., EPC) model was used for the merge. According to certain example embodiments, the connecting may be deterministic, e.g., such that the result will be the same regardless of order or sequence in which the propagations are made.
According to certain example embodiments, the connecting algorithm includes finding the target-side successor and predecessor elements (together referred to as border elements) of the target model object that is being propagated; using trace information to find the source-side elements corresponding to the target model predecessors and successors; optionally deleting border-spanning connections (e.g., if a change propagation action is performed during conflict resolution); and creating connections to and from the propagated object.
Still another aspect of certain example embodiments relates to propagating changes notwithstanding internal inconsistencies in a model.
In certain example embodiments, a method of propagating changes made in a first computer-represented model to a second first computer-represented model is provided. Input corresponding to at least one change to the first model is received, with the at least one change indicating that at least one object in the first model has been added, modified, and/or deleted. An instruction to propagate the at least one change made to the first model to the second model is received. At least one corresponding change propagation action (CPA) is executed, via at least one processor, to cause the at least one change made to the first model to be propagated to the second model in whole or in part as appropriate in achieving consistency between the first and second models following said executing. The at least one CPA including instructions that, when executed, comprise: determining whether the at least one change propagation action can be applied for the at least one change, and when it is determined that the at least one change propagation action can be applied for the change, linking the at least one object to at least one other object in the second model. Each said CPA corresponds to one or more corresponding transformation patterns or rules and includes program logic executable by the at least one processor to carry out the respective transformation pattern(s) or rule(s) in inverse direction(s). The first model is a technical-oriented model and the second model is a corresponding business-oriented model, or vice versa.
In certain example embodiments, a modeling system is configured to enable a user to propagate changes made in a first computer-represented model to a second computer-represented model. The system comprises processing resources that include at least one processor and a memory. The processing resources being programmed to: accept input corresponding to at least one user-specified change to the first model, with the at least one change indicating that at least one object in the first model has been added, modified, and/or deleted; receive an instruction to propagate the at least one change made to the first model to the second model; and execute at least one program logic bundle, selected from a group of executable program logic bundles, in order to selectively cause some or all alterations associated with the at least one change made to the first model to be propagated to the second model so that the first and second models become consistent with one another at least in one or more area(s) affected by the propagation. The at least one program logic bundle being programmed to: determine whether the at least one program logic bundle can be applied for the at least one change, and when it is determined that the at least one program logic bundle can be applied for the change, link the at least one object to at least one other object in the second model. Each program logic bundle corresponds to at least one respective transformation pattern or rule to be selectively applied in inverse direction(s) upon execution. The first model is a target of a transformation and a source of a propagation, and the second model is a source of the transformation and a target of the propagation.
According to certain example embodiments, the linking may includes, for an object added in the first model: (a) creating one or more corresponding elements in the second model; (b) searching for border objects adjacent to the object added in the first model that do not have a merge state conflict; (c) for each border object in the first model, identifying a corresponding border object in the second model; and (d) for each path from the object added in the first model to a border object in the first model: when there are one or more objects along the path, adding a direct connection from the object added in the first model to the respective border object, setting a merge state of the direct connection to indicate that it was added in the first model, and creating one or more corresponding connections in the second model; and otherwise: removing an added in target merge state from the existing single connection and adding one or more corresponding connections in the second model.
In certain example embodiments, there is provided a method for selectively propagating changes made in a first computer-represented model to a second computer-represented model across a modeling system comprising processing resources including at least one processor. An instruction to propagate at least one change made to the first model to the second model is received, with the change corresponding to an object being added in the first model. At least one corresponding change propagation action (CPA) is executed, via at least one processor, to cause the at least one change made to the first model to be propagated to the second model. The at least on corresponding CPA is practiced by: performing an enablement check to determine whether the at least one CPA can be applied for the at least one change, and when the enablement check indicates that the at least one CPA can be applied for the change, connecting the at least one object to at least one other object in the second model. The connecting is practiced, in connection with the processing resources, by at least:
(a) finding first model side border elements of the first model object that is being propagated o1st including:                (i) storing all outbound directed paths that start at o1st and follow added-in-first-model connections to a list of outbound paths, pathout={path1out, . . . , pathnout},        (ii) defining a multiset of end objects for the outbound paths succ1st={s11st, . . . , sn1st}, this multiset being first model successors to o1st,        (iii) storing all inbound directed paths that start at o1st and follow added-in-first-model connections (in an inverse direction) to a list of inbound paths, pathin={path1in, . . . , pathmin},        (iv) defining a multiset of start objects for the inbound paths pred1st={p11st, . . . , pn1st}, this multiset being first model predecessors to o1st, and        (v) defining the union of the first model predecessors and successors succ1st∪pred1st=border1st, this union being the set of first model border objects;        
(b) using trace information to find elements in the second model corresponding to the first model predecessors pred2nd{p12nd, . . . , pn2nd} andsuccessors suce2nd={s12nd, . . . , sn2nd}, and
(c) for each pi2ndεpred2nd (or each sk2ndεsucc2nd):                (i) creating a connection from pi2nd to o2nd (or from o2nd to sk2nd) in the second model, wherein o2nd is the second model counterpart to o1st.        
According to certain example embodiments, (c) may further include:                (ii) if a length of the path pathiin length(pathiin) (pathkout length(pathkout)) corresponding to pi2nd (sk2nd) is 1:                    removing an added-in-first-model merge state of this path's single connection in the first model,            and otherwise creating a connection from pi1st to o1st (or from o1st to sk1st) in the first model and setting a merge state thereof to added-in-second-model.                        
According to certain example embodiments, it may be desirable to, between (b) and (c), determine whether the corresponding CPA is performed during conflict resolution and, if so, for every pair (pi1st, sk1st) with pi1stεpred1st and sk1stεsucc1st for which there exists a connection cxn1st from pi1st to sk1st (or from sk1st to pi1st) whose merge state is added-in-second-model, deleting this connection cxn1st and delete cxn1st's corresponding connection cxn2nd in the second model from pi2nd to sk2nd (or from sk2nd to pi2nd) in the second model.
In certain example embodiments, a computer-implemented method of propagating changes made in a first computer-represented model to a second computer-represented model is provided. Input corresponding to at least one change to the first model is received, with the at least one change indicating that at least one object in the first model has been added and/or modified. At least one enablement check is performed to determine whether the at least one change can be propagated to the second model; and if so, the at least one change is propagated to the second model. The propagating comprises connecting the at least one object to at least one other object in the second model in accordance with at least one transformation pattern or rule.
In certain example embodiments, a modeling system for propagating changes made in a first computer-represented model to a second computer-represented model may be provided for carrying out this method.
Non-transitory computer readable storage mediums tangibly storing instructions for performing the above-summarized and/or other methods also are provided by certain example embodiments, as well as corresponding computer programs.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.